As technology advances, systems/solutions providers develop and offer software applications including increasingly larger numbers of software modules. In order to reduce development costs, software applications offered by providers increasingly utilize software modules from commercial suppliers and open source projects (in place of developing all software modules in-house). While using software modules from commercial suppliers and open source projects provides some advantages for systems/solution providers, using software modules from commercial suppliers and open source projects also results in different costs for systems/solutions providers, and presents many additional challenges for systems/solutions providers, especially in terms of managing resources during the development cycle.
There are different development costs associated with using software modules from commercial suppliers and open source projects. In general, the development costs are related to the number of third-party software modules integrated into the product, and differences in the sizes of originally-deployed versions and the newly-available versions of the software modules. These development costs typically cause providers to carefully determine which sourced software modules should be patched/updated/upgraded (and which patches/updates/upgrades should be ignored). Disadvantageously, however, due to the large number of third-party software modules used by providers in software applications, rather than reviewing every software patch, update, and upgrade of every sourced module in the software application, providers often direct resources toward other development areas/activities perceived to be more important to the overall development of the software application.
Since such sourced modules are developed by numerous different commercial suppliers and open source projects, software patches, updates, and upgrades are on independent development schedules and, thus, there are rarely synchronization points when providers have an opportunity to review and update all the different third-party software modules. Additionally, as the software development cycle progresses it becomes increasingly difficult for providers to introduce patches, updates, and upgrades of sourced modules for inclusion in the release currently being developed. Thus, if the provider determines that a patch, update, or upgrade of a sourced module is required, introduction of the patch, update, or upgrade of a sourced module may impact the delivery of the current release, and even subsequent releases depending on the impact of the patch, update, or upgrade to the development cycle.
Furthermore, in addition to the concerns of providers with respect to development costs and development cycles, the rapid evolution, and hazardous nature, of computer security threats makes it even more important for providers to perform due diligence with respect to patches, updates, and upgrades of sourced software modules, in order to ensure that security fixes, stability fixes, and other bug fixes are appropriately considered. Moreover, providers face increasing commercial risks associated with software applications, e.g., when a software application is shipped to a customer and that software application is subsequently attacked via a previously-known security flaw that had been patched in an updated version of the sourced module that was available and could reasonably have been included by the system/solution provider in the shipped system/solution.